Skip to main content
Version: 12.10.0

Repository Creation and Pipeline Setup

1. Purpose​

The purpose is to share the guideline to developers who set up and maintain repositories for backend services of Navida Pro on how to structure their repositories. The need for certain structural requirements arises from the fact that all backend repositories are being processed by System team tools and pipelines automatically in the CICD chain.

Complying with the guideline ensures that a new repository can be integrated into the CICD chain immediately and avoid extra steps for both repository and pipeline maintainers.

Additionally, having a common structure helps all involved people understanding development and deployment processes throughout the various backend services.

2. Process​

  1. Repository Creation:

    • PoD Developers shall request release management team/PoD Leads to create the repository for new Backend Service.
    • Repository creation access in Bitbucket is not granted to all developers.
    • Ensure the new BE repository structure is adhered to existing BE service.

  2. Branching Strategy:

    Please refer this guide to read more about BE Branching Strategy this

    The following branches should be present in each repository:

    Branch(es): Feature

    A repository can have multiple feature branches. All feature specific development is done within their respective branch.Feature branches can be merged into the ‘release/develop’ branch via pull request.

    Branch: release/develop

    All commits within this branch are deployed in internal Azure in the environment commonly referred as ‘dev’ (namespace name is ‘ey’). For QA verfication purpose we have testing environment referred as ‘tst’ (namespace name is ‘tst’).

    Additionally, the content of this branch can be deployed in the external pre-production environment (SAPM or SAPW) by tagging a commit with a proper version tag.

    This branch can be merged into the ‘master’ branch via pull request.

    Branch: master

    This branch represent the production environment. Once a version (tagged commit) from pre-production has been approved an is released in production, the commit is merged via pull request into the ‘master’ branch.

    Branch: systemteam

    The ‘systemteam’ branch is a special type of feature-branch used for AOK-internal changes that may circumvent the approval chain from the regular pull requests.

    This feature branch should only be used in exceptional cases.

    After completion of new Repository development, needs to be intimated to System team through JIRA to enable the applicable pipelines for the newly created service.

    • Sonar build Pipeline for new/modified PR
    • Sonar build Pipeline for code merge into release/develop branch
    • Build Pipeline for dev/tst/sapw(m) tagging

  3. Pipeline Setup:

3. Conclusion​

Following the process effectively is essential for ensuring to improving standards and overall team collaboration.